add API-Name aka wild-card scope #103
Conversation
Signed-off-by: Axel Nennker <[email protected]>
AxelNennker
requested review from
bigludo7 and
fernandopradocabrillo
as code owners
|
@AxelNennker after reading the related issue I think we should wait for ICM final decision before adding anything |
Hi @fernandopradocabrillo , hi @bigludo7 , I believe that "wildcard" and "purpose" were mixed together in ICM's purpose discussion because an example about "purpose" contained a wildcard scope.
Now we have "purpose" defined in Camara Security and Interoperability Profile. I think because scope guidlelines are in https://github.com/camaraproject/Commonalities/blob/main/documentation/API-design-guidelines.md#1161-scope-naming the "wild-card" or <API-Name> guideline should be there. I guess, if the SimSwap-WG wants to wait on scope guidelines then we should wait for Commonalities. |
code/API_definitions/sim_swap.yaml
Outdated
| - openId: | ||
| - sim-swap:retrieve-date | ||
| - openId: | ||
| - sim-swap |
There was a problem hiding this comment.
I think we don't need to repeat the "openId", we can just add it to the existing array
| - openId: | |
| - sim-swap:retrieve-date | |
| - openId: | |
| - sim-swap | |
| - openId: | |
| - sim-swap:retrieve-date | |
| - sim-swap |
There was a problem hiding this comment.
I think that two scopes mean that both scopes must be in the access token at the same time.
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#security-requirement-object
If the security scheme is of type "oauth2" or "openIdConnect", then the value is a list of scope names required for the execution, ....
For example if the API has a scopes "write:pets" and "read:pets" then the "manage" endpoint requires both scopes, while the getById endpoint just needs "read:pets".
The way I proposed means: "one of the security objects must fit"
So, I think, that
- openId:
- sim-swap:retrieve-date
- openId:
- sim-swap
means that if the access token has scope sim-swap:retrieve-date then pass or if the access token has scope sim-swap then pass.
The client can thus request an access token with the scope sim-swap and the the AZ grants it. Then that access token has the scope sim-swap and the RS would let the API-request pass at both the two endpoints.
There was a problem hiding this comment.
Yes, I did more research and indeed you are right so we can proceed this way
|
Good ! thanks @fernandopradocabrillo for the research. |
bigludo7
dismissed stale reviews from fernandopradocabrillo and themself
via
f1a3e28
Fixed MegaLinter issues
|
@fernandopradocabrillo I've fixed megalinter issues so review required :) |
done! and I won't charge you extra :) |
What type of PR is this?
Allow clients to request the scope
sim-swapand get access to both sim-swap-check and sim-swap-dataWhat this PR does / why we need it:
Let the SimSwap subgroup define support for the wildcard scope
sim-swap.See also: camaraproject/Commonalities#184 (comment)